Specification Structuring

Programs that accept inputs, compute and produce outputs are specified by describing all possible inputs and the corresponding outputs. When the possible inputs are finite in number—as is the case with combinatorial circuits, for instance—the input,output pairs may be explicitly enumerated. However, for most programs it is convenient to describe input,output by logical propositions such as a precondition-postcondition pair, or the weakest precondition. In this paper, we are interested in systems that typically run forever, responding to changes in some of their input variables by changing their internal states and/or some of their output variables. Example of such a system is a feedback controller that responds to a sensor reading by adjusting the valve opening, or a display program that responds to a keystroke by echoing the appropriate character on the screen. Such systems, called reactive by Amir Pnueli, are ubiquitous in all modern computer and communication systems. They cannot be specified merely by their input-output pairs, because input may be provided and output extracted on a continuing basis. Furthermore, these systems typically exhibit a high level of nondeterminism because the system may respond to inputs from many sources in an apriori undetermined order: A telephone switch that is connected to a number of users serves them in a seemingly random order. We are interested in specifications of such systems for all the traditional reasons: We expect a specification to be a contract between the user and the implementer; the user may assume nothing more than what has been specified explicitly and the implementer must satisfy the specification through his implementation. This allows the user programs to change as long as they all obey the protocol set forth in the specification; similarly the implementation may change as long as it is faithful to the specification. We view specification not merely as a legal contract but additionally as a means (1) to deduce new properties (of the “module” being specified), (2) to deduce properties of a system in which the given module is a component, and (3) to implement the module by stepwise refinements of its specification. Therefore, we require that a specification not merely be formal but also be in a form that admits of effective manipulation. This requirement rules out specification schemes in which program fragments (in some high level language) appear as part of specifications; typically, such program fragments cannot be manipulated effectively. A specification of a large system will typically be large. Therefore, in the best traditions of software engineering, we have to structure the specification. Methodologies for program structuring have evolved over the years; now, we know that a program may be decomposed into modules based